A security token is typically an electronic device, which is light and small in order to be easily carried by a user (fits easily in a pocket). It is most often personal. In general, a security token is a resource constrained device, in that at least one of the following is true: its processor is not very powerful, it has little memory, it does not have a source of power (battery etc.) nor a user interface, i.e. in order to interact with the security token a user typically needs to connect the security token (either in contact or in contact-less mode) with a terminal, which provides some power as well as means to input data into the security token and/or to display or otherwise communicate to the user (e.g. with a sound card, an LED, a buzzer, a vibrator, etc.) certain information sent by the security token. More elaborate security tokens may embed a battery, and/or have input/output capabilities such as a small pinpad, or a small LCD.
The most widespread example of security token is probably the smart card. Billions of smart cards are used in the world, and allow card holders (people carrying the smart card) to authenticate themselves e.g. to a financial institution (e.g. when making payment with a bank card), to a telecom operator (e.g. when passing phone calls with a GSM phone equipped with a SIM card), or to a government organization (e.g. when authenticating with a healthcare smart card, ID smart card, or electronic passport). Many other types of security tokens exist, for example USB keys, parallel port dongles, OTP tokens (OTP stands for One Time Password), TPMs (trusted platform modules, specified by the Trusted Computing Group, and which typically allow to secure a computing device by verifying in particular that the hardware components are not modified, and that any software it runs has the good version and has been properly signed), etc.
During the last decade, the number of security tokens embedding a virtual machine has grown significantly, in particular with the advent of JavaCard, and more recently .NET cards. Such security tokens are advantageous because they can be easily programmed by loading an applet into them (e.g. Java applet, .Net applet, etc.). Due to the fact that security tokens are generally resource constrained, the standards in place (e.g. Java) had to be adapted (for smart cards, it became JavaCard) in order to guarantee that an applet is able to run on the security token. E.G. certain “complex” operations (such as floating point operations) are sometimes not supported.
The JavaCard platform is defined primarily by the following three specifications:                Virtual Machine Specification for the JavaCard™ Platform        Application Programming Interface for the JavaCard™ Platform        Runtime Environment (JCRE) Specification for the JavaCard™Platform        
The most widespread version of JavaCard is presumably version 2.1, but version 2.2.1 will probably soon become the most widespread. Version 2.2.2 is expected to be the dominant version in the mean term. Version 3 has been released recently but has not yet been widely deployed, it will probably happen a bit later.